ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group98a.txt/000003_icon-group-sender _Mon Jan 19 09:31:48 1998.msg

Internet Message Format | 2000-09-20 | 5KB

Return-Path: <icon-group-sender>
Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
    by baskerville.CS.Arizona.EDU (8.8.7/8.8.7) with SMTP id JAA24835
    for <[e-mail]>; Mon, 19 Jan 1998 09:31:48 -0700 (MST)
Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
    id AA29406; Mon, 19 Jan 1998 09:31:48 -0700
X-Sender: [e-mail] (Unverified)
Message-Id: <v04003901b0e8af42376d@[204.148.87.172]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 19 Jan 1998 01:52:38 -0600
To: [e-mail]
From: "Nevin :-] Liber" <[e-mail]>
Subject: Re: Stripping blank and comment lines
Cc: "Gordon Peterson " <[e-mail]>
Errors-To: [e-mail]
Status: RO
Content-Length: 3598

"Gordon Peterson " <mailto:[e-mail]> writes:
>In a sorted XREF, it's absurd to sort variables principally by their data type
>anyhow.

Personally, I don't find alphabetical sort order for variables to be all
that useful; I'd much rather see them in order of declaration (and I always
use local declarations in Icon) or order of use.  And I usually don't have
many variables within a function; if it gets to be a lot, I usually just
declare another function.

>If you have a number of variables regarding dates, for example, you'd
>want things like DateP (date pattern), DateMonth, DateYear, DateDay,
>DateWkDay,
>DateLeap, etc to all sort together in the Xref, regardless of that some of
>them
>might be flags, others might be character strings, others might be
>patterns and
>some might be numbers.

In your above example, you have no way of telling if DateMonth is a string
or a number.  And in Icon, it matters, as if you were comparing two months,
you'd have to know whether to use "=" or "==".

This is the essence of why I personally use this convention for naming my
variables.  While it does in some sense break abstraction, in practical
terms, you need to know what type of object is stored in a variable in
order to manipulate it.

>I'm not accusing the poster of originating this claptrap,

I think the origin is by Charles Somoyi (sp?) at Microsoft and his
Hungarian notation.  Ironically, I don't use it much in C, as objects are
either numbers (char, int, short, long, enums) or structs/unions.  The way
to manipulate a number in C is the same whether it is an unsigned char or a
long (although the limits of what they can represent are different), and I
can go back to the type declaration for the few times I need to know what
kind of number it is (eg: when writing a printf() statement).  I do use
"Ptr" and "Hdl" as suffixes on variables, since that is usually information
needed to know how to get to the object.

I'm just trying to find the right balance between abstraction and the
practical side of having to maniplate the values stored in variables.

>but I do think it's
>interesting that so many people, lemming-like, adopt such absurd conventions
>that some obvious loon dreams up and proposes as a naming convention
>"standard".

There are reasons behind the convention, even if you don't necessarily
agree with them.  Evem the argument of "because everyone else is doing it"
has some merit, if you have to be sharing your code with other people who
adopt that convention.

>It's especially strange in a language like Icon or S*BOL where the type of a
>variable can be QUITE variable during the execution of a program!

While that is theoretically true, it rarely occurs in the programs that I
write.  I very rarely use a variable to represent more than one type of
value (&null sometimes being an exception to this rule, although even this
doesn't occur very often).  If I have a different type, I just declare a
different variable.  About the only time it does occur in my code is when I
am taking values out of one of the structure types (tables, lists, sets,
records) or during parameter passing.

>Again, please don't take this as a personal attack on the poster

No offense taken here.  People ought to think about why they have certain
styles of coding.

--
 Nevin ":-)" Liber  <mailto:[e-mail]>  [phone]
  Senior Software Engineer, Pendragon Software <http://www.webfayre.com/>

    Pendragon Software Corporation
    1580 South Milwaukee Avenue, Suite 515
    Libertyville, IL 60048-3776
    voice:    [phone]
    fax:    [phone]